The delivery of content via the World Wide Web (www or web) has been determined, to a large degree by the specification of file types and protocols for the encoding of the delivered content.
HTML was the first specification that was commonly accepted by publishers of information on the internet, as well as those organisations that built the web browsers for parsing the published information so that the information was displayed on the users screen as intended by the publisher.
Early specifications of the HTML standard were very text based and did not deal with multimedia elegantly. Consequently, web developers were unable to provide in early websites, the rich interactivity that applications that ran in the user's operating system provided.
As a result of this, many browser plug-ins providing runtime environments were developed such as Adobe Flash, Sun Microsystems Java and Microsoft Silverlight. These plug-ins allowed a publisher to deliver binary code over the internet that would execute in the plug in run time environment resulting in a rich user experience that allowed the development of “web apps” or applications that are delivered through the user's browser that appear to be applications like any other application that would run on a user's computer in their operating system environment.
The increase in the information stored and marked up in X/HTML has resulted in the need for increased X/HTML compatibility in plug ins that have their own different standards and document formats.
It would be desirable to be able to have one of the more modern runtime environments be able to use X/HTML element as its own as the majority of data online is available as X/HTML. It would be desirable that Silverlight executables which run in the Silverlight run time environment be able to contain the X/HTML that has come from these increasing sources.
Silverlight is a rich internet application platform which has many modern features such as styling, templating, being programmable in different computer languages and having a large library of functions. It would be desirable for X/HTML to be able to be taken into Silverlight to use its modern features.
Another benefit of having X/HTML compatibility in Silverlight Applications is that the developer can keep pre-existing investments in Content Management Systems that are great with creating X/HTML and have that passed into Silverlight.
A third benefit of improved X/HTML compatibility in Silverlight would be that it could speed up the creation of Silverlight Applications. X/HTML documents can form the starting point for a new application.
A fourth benefit to X/HTML compatibility in Silverlight is that of skill reuse. Professional skilled X/HTML creators could create the X/HTML that forms the data and meaningful mark up and then style, template, and mix the X/HTML in with Silverlight controls and application code in order to write a Silverlight Application.
A fifth benefit to X/HTML compatibility in Silverlight is that it would provide a way for X/HTML to be used in Silverlight editors such as the design tool Expression Blend and the programming tool Visual Studio which aid Silverlight designers and developers to create applications.
This desire for Silverlight to be more compatible with X/HTML is shared amongst those skilled in the art.
Notwithstanding a long felt want in the area, there is no method or product available to make Silverlight work with X/HTML like it does with its own Silverlight controls. It would appear that the failure to develop a method or product to do this is a result of the following obstacles:
(1) the set of Silverlight controls that are packaged with Silverlight are not equivalent to the set of X/HTML elements. Whilst it is possible to use the closest set of controls in Silverlight to the X/HTML by changing the names of the X/HTML elements used in the source document to the closest match in the Silverlight elements, changing the name leads to a loss of the markup which is meaningful (for example, a <footer> element means the contents is a footer, renaming it to an Silverlight control will lose this name). There is large number of elements without a close match and prior art simply drops support for these elements.
(2) Silverlight uses XAML not X/HTML as a markup language. However converting X/HTML to XAML is useless as the Silverlight Plug-in requires there to exist Silverlight controls with the elements and attributes the X/HTML has used.
(3) The complete process of creating the missing Silverlight custom controls with the same element and attribute names, correcting any incompatibilities in X/HTML document to the XAML document format and the final step of adding that XAML to a Silverlight Application along with the missing controls has been considered too difficult to be achievable.
Therefore making Silverlight more compatible with X/HTML hasn't been provided in an extensive way that makes the X/HTML work the way Silverlight does.
There have been a few partial solutions to converting X/HTML to Silverlight. These include:                (1) HTML overlay, this is where the X/HTML is put in a div or iframe and overlayed on top of the Silverlight Application. A limitation of this is that the overlayed X/HTML is not visually presented by Silverlight and misses out on the Silverlight plug-ins capabilities. Another limitation is that it's not part of the Silverlight Application and is therefore not really converted, but simply shown on top of the Silverlight Application.        (2) Silverlight 4 will have a browser control which will handle X/HTML but not in all situations, it will allow the Silverlight Application to show X/HTML when the application is running in Out-Of-Browser mode, which is when it is running as a desktop application. This has many limitations, first it doesn't work while the application is running in the browser, second the browser control doesn't convert the X/HTML to XAML for editing or saving; thirdly this doesn't provide the individual controls needed to create a nested tree, that is it doesn't convert the X/HTML DOM to the Silverlight Object Model. The last two points are important as the developer won't be able to manipulate the result, nor restyle it.        (3) Rename X/HTML to closest XAML. This partial solution describes converting the X/HTML by renaming it to Silverlight XAML that matches some of the functionality. For example, converting a <h1> element to the XAML <TextBlock Fontsize=“15”> element. This doesn't keep the Mark-up information that the element implies, that is that the text is the First Heading. Nor does it provide the custom control h1 that would be required to do so. Instead it reuses existing controls like the TextBlock, changing settings on these controls to mimic the look the browser gives the X/HTML or to simply present the data portion of the hypermedia document. This solution is manually trying to mimic the look and feel of X/HTML while being very limited to text and the few Silverlight controls that are similar to X/HTML.        
Each of these attempts has failed to provide a robust method for accurately converting X/HTML to Silverlight formatted documents.
Persons skilled in the art have been discouraged from producing a tool of the present invention because they have been misguided by conventional thinking. Conventional thinking is that Silverlight is too different to X/HTML. Generally prior art attempts at providing a convertor of the present invention have resorted to providing either custom controls for Silverlight or providing an HTML to XAML parser for Silverlight or WPF/E.
The majority resign to either overlaying the X/HTML or reading the text of the X/HTML document in and then showing it as plain text on screen.
Neither of these approaches would result in an adequate tool for conversion. These approaches cannot convert X/HTML and make it flexible for the developers. The functions that would be absent are the templating features, the ability to relate the X/HTML to Silverlight controls predictably and the benefit to those skilled in X/HTML that the Silverlight XAML created is named similar to the X/HTML they are used to. The flexibility that comes from these features are that the styling and templating creates a larger control over the look of the document. The converting to unique Silverlight custom controls results in finer grained control over the resulting conversion, that is that the Silverlight programmer my choose to add and other Silverlight controls in to the converted document after the conversion or remove some of the converted X/HTML once it is in Silverlight object form.
It is an object of the present invention to overcome the X/HTML limitations in Silverlight and some of the stated deficiencies in the prior art and to provide a method to convert X/HTML to Silverlight Applications in such a way that the result can have its visual presentation customised.